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Foreword 



rd , 



This Technical Specification (TS) has been produced by the 3 Generation Partnership Project (3GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 
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1 Scope 

The present document specifies the stage 2 description for the Follow Me feature. 

The Follow Me feature enables a mobile subscriber A to manipulate the Follow Me data of a remote party B in such a 
way that subsequent calls directed to remote party B will be forwarded to subscriber A. 

2 References 

The following documents contain provisions which, through reference in this text, constitute provisions of the present 
document. 

• References are either specific (identified by date of publication, edition number, version number, etc.) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including 
a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same 
Release as the present document. 

[I] 3GPP TR 21.905: "3G Vocabulary". 

[2] 3GPP TS 22.004: "General on Supplementary Services". 

[3] 3GPP TS 22.030: "Man-Machine Interface (MMI) of the Mobile Station (MS)". 

[4] 3GPP TS 22.082: "Call Forwarding (CF) supplementary services - Stage 1". 

[5] 3GPP TS 22.094: "Follow Me (FM) feature - Stage 1". 

[6] 3GPP TS 23. Oil: "Technical realisation of Supplementary Services - General Aspects". 

[7] 3GPP TS 23.015: "Technical reaUsation of Operator Determined Barring (ODB)". 

[8] 3GPP TS 23.090: "Unstructured Supplementary Services Data (USSD)- Stage 2". 

[9] 3GPP TS 23.082: "Call Forwarding (CF) supplementary services - Stage 2". 

[10] 3GPP TS 22.090: "Unstructured Supplementary Services Data (USSD)- Stage 1". 

[II] 3GPP TS 24.090: "Unstructured Supplementary Services Data (USSD)- Stage 3". 
[12] 3GPP TS 29.002: "Mobile Application Part (MAP)". 

3 Definitions and abbreviations 
3.1 Definitions 

initiating subscriber: mobile subscriber who modifies the Follow Me data of the remote party. 

initiating number: number (the MSISDN of the initiating subscriber) to which incoming calls, originally destined for 
the remote party, shall be forwarded. It is subsequently also referred to as MSISDNa. 

remote party: is characterised by the remote number which is defined in the numbering plan of a PLMN operator. The 
Follow Me feature enables the initiating subscriber to modify the Follow Me data of the remote party. In particular 
cases the remote party is a GSM subscriber of the PLMN and the remote number denotes her basic MSISDN. 
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FM service supervisor: is an initiating subscriber who is allowed to modify the Follow Me data of a remote party who 
has been registered to another initiating subscriber for the Follow Me application. The FM service supervisor shall be 
authorised by her network operator. 

remote number: is a number in E.164 format which identifies a remote party. In general this number is not assigned to 
a subscriber and can be regarded as a "dummy MSISDN". In particular cases the remote party is a GSM subscriber of 
the PLMN and the remote number denotes her basic MSISDN. The remote number is entered by the initiating 
subscriber for registration, interrogation, forced erasure and erasure of the Follow Me feature with respect to the remote 
party. 

Follow Me function node: is a network node in the PLMN operator of the remote party. The FM data of the remote 
party are stored in this node. This node can be implemented in: 

- an HLR; 

any other operator specific network node e.g.: 

- a gsmSCF; 

- an SCP. 

3.2 Abbreviations 

FFN Follow Me function node 

FM Follow Me 

SCP Service Control Part 

Other abbreviations used in this ETS are listed in 3GPP TR 21.905. 



Handling of Follow Me 



4.1 General 

Follow Me enables an initiating mobile subscriber A to have control over the Follow Me data of a remote party B. The 
remote party B is characterised by the remote number which is defined in the numbering plan of a PLMN operator. 
Initiating Subscriber A shall be able to manipulate the Follow Me data of remote party B such that subsequent calls 
destined for remote party B are forwarded to initiating subscriber A. In the case of Forced Erasure by an FM service 
supervisor, the initiating subscriber is allowed to erase the Follow Me data of a remote party who has been registered to 
a different initiating subscriber for the Follow Me application. 

Follow Me is a PLMN specific feature and the control operations of FM are based on USSD. All messages between the 
MS and the mobile network and internal to the mobile network are USSD messages. 

The present document deals with the control operations of FM in HLRa and FFN. If the FFN is an HLR, the control of 
the requests for both FM and CFU services is specified (see subclause 4.3.2). 

The functionality of forwarding calls for remote party B to initiating subscriber A (after successful registration of FM) 
is out of the scope of the present document. This functionality is the same as the functionality of the Call Forwarding 
Unconditional Supplementary Service applied to all telecommunication services of remote party B for which CFU is 
applicable. 

NOTE 1: the "served mobile subscriber" in [5] corresponds to the "remote party" in the present document and the 
"forwarded-to subscriber" in [5] corresponds to the "initiating subscriber" in the present document. 

NOTE 2: The forwarding of calls for remote party B to initiating subscriber A can be achieved by invoking the Call 
Forwarding Unconditional Supplementary Service or by making use of an equivalent operator specific 
service (e.g. via CAMEL). 

The functionality of the control of Follow Me (registration, erasure, forced erasure and interrogation) is split between 
the HLR of the initiating subscriber A (HLRa) and the FFN of the remote party B (FFNb). 
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4.1.1 Provision 

FM can be registered / erased / interrogated by an initiating subscriber A with respect to a remote party B if both parties 
are provisioned with FM. 

To enable forced erasure by an FM service supervisor, the FM service shall be provisioned to the FM service 
supervisor. Additionally, she needs the subscription entitlement to perform the forced erasure. 

NOTE: In general remote party B does not correspond to a GSM subscriber. In this case provisioning of FM for 
remote party B is operator specific. 

If remote party B is a GSM subscriber and if the forwarding of calls for remote party B to initiating subscriber A is 
achieved by invoking the Call Forwarding Unconditional Supplementary Service, provision of CFU for remote party B 
is required. 

4.1.2 Registration 

The initiating subscriber registers the FM feature with respect to a particular remote party. 

If an initiating subscriber A successfully registers FM with respect to a remote party B then FM becomes registered, 
active and operative for remote party B. 

As a result of the registration subsequent calls directed to remote party B are forwarded to initiating subscriber A. 

NOTE: The remote party cannot register FM with respect to herself. 

4.1.3 Erasure 

If an initiating subscriber A or the FM service supervisor successfully erases FM with respect to a remote party B then 
FM becomes not registered and not active for remote party B. 

If remote party B is a GSM subscriber and successfully erases FM then FM becomes not registered and not active for 
remote party B. 



4.1.4 Interrogation 

If an initiating subscriber A or the FM service supervisor successfully interrogates FM with respect to a remote party B 
then this procedure interrogates the FM data of subscriber B. 

If remote party B is a GSM subscriber and successfully interrogates FM then this procedure interrogates her own FM 
data. 

4.2 Information Flows 

4.2.1 Information Flow for the handling of FM by the initiating subscriber 

Figure 4. 1 shows the Information Flow for the control of FM (registration, erasure, forced erasure and interrogation) by 
the initiating subscriber. 

For any control operation on FM, the initiating subscriber (MSa) enters a Follow Me Request (FM-Request). This is a 
USSD string containing the requested FM operation and the remote number. The Follow Me Request is routed via the 
MSC/VLR to the HLR of the initiating subscriber (HLRa). 

The HLRa performs a series of checks as described in the SDLs (subclause 0). If these checks fail, the MSa receives a 
response (FM-Response) indicating the error. 

If the checks pass, the HLRa forwards the operation request (HLR-FM-Request) to the FFN of the remote party (FFNb). 

FFNb carries out the appropriate control operation and checks as described in the SDLs (subclause 0) for the remote 
party. 



£75/ 



3GPP TS 23.094 version 5.0.1 Release 5 



ETSI TS 123 094 V5.0.1 (2002-07) 



The result of this operation (success or error) is reported back in a USSD Response to the initiating subscriber. 



MSa MSC 

FM-Request 



VLR 



HLRa 



FFNb 



(OC,SC,RN, 

[(SI,PIM,)] [AI]) 



FM-Response 
(EiTor) 



FM-Response 
Result) 



FM-Request 



(OC,SC,RN, 
[(SI,PIM,)] [AI]) 



FM-Response 
^rror) 



FM-Response 
Result) 



FM-Request 



(OC,SC,RN, 

[(SI,PIM,)] [AI]) lORl 

N 

FM-Response 

(Error) 



ORl 
Y 



FM-Response 
Result) 



HLR-FM-Request 

► 

(OC,SC,RN,AI; 

[(SI,PIM,)] [AI,] 

MSISDN-A) 

HLR-FM-Respons 
Result) 



Figure 4.1 : Information flow for the control of FM by the initiating subscriber 

NOTE 1: ORl:N: The case where the checks in the HLR resuh in a negative outcome, e.g. FM is not 

provisioned for the initiating subscriber or the initiating subscriber is not allowed to operate FM for 
the remote party. 

0R1:Y: The case where all the checks in the HLR are successful, e.g. FM is provisioned for the 
initiating subscriber and the initiating subscriber is allowed to operate FM for the remote party. 

NOTE 2: [...]Optional parameter. 

(...)] Conditional parameter. 

OCOperation Code (Register, Erase or Interrogate). 

SC Service Code for FM. 

RNRemote Number. 

SI Supervisor Indicator. This parameter is conditional and only used for forced erasure by a FM 
service supervisor. 

PIM MSISDN of previous initiating subscriber who has registered the FM to remote number. This 
parameter is conditional and only used for forced erasure by a FM service supervisor. 

AI Supplementary Information containing additional information. 

MSISDN-A initiating number in international format. It is not a part of the USSD string, but is sent 
from HLRa to the FFNb together with the HLR-FM-Request within the MAP operation. 

4.2.2 Information Flow for the handling of FM by the remote party 

Control of FM by the remote party is possible if the remote party is a GSM subscriber. 
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The information flow for control of FM by the remote party (erasure and interrogation of her own FM data) is the same 
as the information flow for control of FM by the initiating subscriber. 

If a remote party tries to register FM to herself the registration is rejected and an error is reported. 

4.3 Handling of FM control in HLRa and FFNb 

HLRa and FFNb can both receive FM control messages, based on USSD. The USSD handler in each entity analyses the 
Service Code contained in the USSD string and, recognising the Service Code for FM, invokes the FM USSD 
application. 

The FM control messages and their contents are given in Annex B (normative). 

4.3.1 Handling of FIVI controlin HLRa 

The FM USSD application in HLRa is the process FM_initiating_subscriber_handling_in_HLR (figure 4.2). It 
receives the FM-Request from the initiating subscriber. This FM-Request is an USSD-string containing: 

the operation code (register, erase, interrogate); 

the remote number; 

an additional operator specific information field. 

The HLR checks: 

the provisioning of FM to the initiating subscriber; 

whether the FFN can be deduced from the remote number; 

whether any operator specific restrictions to engage in FM activity with the remote party apply; 

if the initiating subscriber requires forced erasure, the HLR checks Whether the initiating subscriber is entitled to 
do it, i.e. Whether the initiating subscriber is a FM service supervisor. 

The basic MSISDN of the initiating subscriber is sent together with the original USSD string to the FFN of the remote 
party. 

The HLR forwards the response from the FFN to the initiating subscriber. 



£75/ 



3GPP TS 23.094 version 5.0.1 Release 5 



10 



ETSI TS 123 094 V5.0.1 (2002-07) 



Process FM_lnitiating_Subscriber_Handling_in_HLR 



1(1) 



A process in the HLR to handlei 
an FM-Request from an initiating^ 
subscriber. 



Signals to/from the left \ 
areto/ftomtheVLRofthe 
initiating subscriber; 
Signals to/from the right 
are to/from the FFN 



Idle 



FM-Request 
(Operation, 
RemoteNumb^ 
Additional Info; 



Error := 
FM not subscribed 



Error := 

unl^nown Remote 

Party 



HLR receives USSD 
I string from initiating 
subscriber 



checl< If Initiating 
subscriber is FM 
provisioned 



checl< If address of FFN 
can be deduced from 
Remote Number 



Error := 

unauthorised 

request 




HLR-FM-Request := 

FM-Request 

-1- initial MSISDN 



Checl< lit the forced erasure 
Is allowed to the rltiaSng 
subscriber. 



check operator specific 
restrictions on initiating 
subscriber to engage 
Remote Party in FM activity 



Basic MSISDN of Initiating 
subscriber is sent to the FFNb 
together with the FM-Request 
within the MAP operation. 



FM-Response 
(Error) 



HLR-FM-Request 

(Operation, 

RemoteNumber, 

Additionaljnfo, 

InifaLMSISDN) 



Idle 



waifor_answer_ 
from FFN 



HLR-FM-Response 
(Result) \ 



FM-Response 
(Result) 



Idle 



Figure 4.2: Process: FMJnitiatingSubscriberHandlingJnHLR 
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4.3.2 Handling of FM control in FFNb 



If the FFN is an HLR, the FFN is responsible for handhng the interactions between FM and CFU. Two kinds of request 
may be received in an FFN which deals with forwarding services: 

CFU requests sent by the VLR for CFU operations (only if the FFN is a HLR); 

FM-HLR-Requests which are USSD strings sent by HLRa for FM operations. 

When the control process in the FFN receives a CFU request, it shall either pass the CFU operation request directly to a 
CFU process or reject it depending on the registration and/or activation states of both FM and CFU services (see Table 
A.l for permission checks). 

On receipt of an HLR-FM request, the control process in the FFN performs a series of FM specific checks and checks 
the states of both FM and CFU. If the checks are successful, a CFU operation request is sent to a CFU process. On 
receipt of an HLR-FM -Request from HLRa, the FFN performs a series of checks, e.g.: 

if the remote party is a GSM subscriber: 

provisioning of FM to the remote party; 

provisioning of CFU to the remote party; 

illegal interaction with CFU registered or active to remote party. 

if the remote number is registered in the FFN; 

if any operator specific restrictions to engage in FM activity with the initiating subscriber apply; 

specific checks for forced erasure. 

Depending on the requested operation, one of the following procedures is performed: 

registration with implicit Activation (procedure Handle_Remote_Party_Registration, figure 4.6); 

erasure with implicit Deactivation (procedure Handle_Remote_Party_Erasure, figure 4.7); 

interrogation (procedure Handle_Remote_Party_Interrogation, figure 4.8). 

Figure 4.3 shows the message flow between the process Forwarding_Service_Control and the processes handling CFU 
operation requests, defined in [9]. 
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1(1) 




'^ 
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[cPU acknowledge] 

1 
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lacknowledge I 
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\ 
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r 






Processes defined 
in 03.82: CFU1, 
CFU2,CPU3 or 
CFU4 



























Figure 4.3: FFN_processes 
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Process Forwarding_Service_Control 

This process describes ,_v 
the case where the FFN is sr 

HLR. Camel or IN solution ' , 

should have the similar ' 
behavior. ' 



1(2) 



Signals to/from the right are K 
loitrom the appropriate CFU 
process. Signals to/from the 
left are to/lrom the VLR 
unless otherwise stated. 



It'sfrom theHLRof 
the ritiating subscribe 




HLR-FM- 
Request (Reg, 
erase, interr., 
forced erasure) 



FM_remotej3arty_ 
handlingJnFFN 



Result := 

Conflicting 

situation 

with other SS 



waitjorresponse 



acknowledge 



acknowledge 



Register CFU ^activate CFU 




X deactivate 
^CFU 



X interrogate 
^CFU 



it should contain the appropiate 
message, e.g. "register CFU" etc. 



if it's an FM-Request, 
J the message is to the VLR 
of the initiating subscriber. 



4.4 Process Forwarding_Service_Control 
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Procedure FM_Remote_Party_Handling_in_FFN 



1(1) 



This process describes the case ; 
where the FFN is an HLR. 
IN solutions should have 
similar behaviour. 



signals to/from the left areL 
to/from the HLR of the 
initiating subscriber 



(- 



Result := 

FMnot 

subscribed 




yes 



Result := 

unknown remote 

party 



Result := 

remote party 

authorisation 

failed 



HLR-FM- 

Response 

(Result) 




check operator specific 
restrictions on remote party 
to be engageed in FM activity 
with initiating subscriber 



handle_Remote_ 
Party_Erasure 



handle_Remote_ 

Party_ 

Registration 



Figure 4.5: Procedure: FM_Remote_Party_Handling_in_FFN 
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Procedure Handle_Remote_Party_Registration 



1(1) 



n>^ 



This process describes the case 
where the FFN is an HLR 
IN solutions should have 
similar behaviour. 



signals to/from the left are|\ 
to/fromtheHLRofthe 
initiating subscriber 
signals to/from the right are 
to/from the CFU processas 
indicated 




Result :- 

request to own 

MSISDN not possible 



FM states := 
registered & active 



Result := 

FM successful 

registered 



result := corresponding 
unsuccessful 
outcome code 




Figure 4.6: Procedure: Handle_Remote_Party_Registration 
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Procedure Register_FM_for_Remote_Party 

This process describes the case \ 
wheretheFFN isan HLR. ^ 

iN solutions shou id have 
simiiar behaviour. 



1(1) 



signals to/from the right arel 
to/from the CFU processas 
indicated. 




to process CFU1 
(GSM 03.82) 



T acl<nowledge 
from process CFU1 \_ r (error) 
(GSM 03.82) I 




ifyes, the initiating 
subscriber repeats 
her previous 
registration 



Result := remote 

party already 

registered 



Figure 4.6a: Procedure Register_FM_for_Remote_Party 
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Procedure Handle_Remote_Party_Erasure 



1(1) 



This process describes the case 
where the FFN is an HLR. 
IN solutions should have 
similar behaviour. 



signals to/from the left are \ 
to/from the HLR of the 
initiating subscriber 
signals to/from the right are 
to/from the CFU process as 
indicated. 



Result := FM 

not reg istered to 

remote party 




if yes, then FM service 
1 supervisor 
performs FM erasure 



Result := Remote 

party not registered 

tothisMSISDN 



result := Remote 
party not 

registered to this 
MSISDN 



Result := 
FM successful 
deregistered 




Result := corresponding 
unsuccessful 
outcome code 


^k 




U 


>h 




/ HLR-FM- 
/ Response 
\ (Result) 





Figure 4.7: Procedure: Handle_Remote_Party_Erasure 
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Procedure Erase_FM_for_Remote_Party 



1(1) 



This procedure is caiied i \ 

by the procedure ^ 

handie„Remotej)arty_Erasure 
after the authorisation checl^s 
have been done. This procedure 
describes the case if the FFN is 
an HLR. Camel or IN solution 
should have the same behavior ' 



signals to/from the left areK 
to/from the HLR of the 
initiating subscriber 
signals to/from the right are 
to/from the C FU process as 
indicated. 



toprocessCFU2 
1 (GSM 03.82) 



Erase_CFU 
(BS = all BS) 



wait_for_ 
response 



from process CFU2 
(GSM 03.82) 



_, acknowledge 
(result) 



acknowledge 
(error) 



from process CFU2 
1 (GSM 03.82) 



Result := pass 



Result := (error) 



Figure 4.7a: Procedure Erase_FM_for_Remote_party 
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Procedure Handle_Remote_Party_lnterrogation 

I \': 

I This procedure describes , , 
I the case whenre the FFN is^ 
I an HLR. IN solutions should ' 
I have similar behaviour. , 



1(1) 



signals to/from the left arel 
to/from the HLR of the 
initiating subscriber 




The MSISDN digits are sent 
" in the USSD response 
separated by a blank 
charader from the outcome 
code 



Figure 4.8: Procedure Handle_Remote_Party_lnterrogation 



4.4 USSD interworking and Cross-phase compatibility 

All the messages between MS and the mobile network and internal to the mobile network, which are used for control of 
Follow Me, are USSD Phase 2 messages. 

A Cross-phase compatibility mechanism specified in [6] for networks or MS not supporting USSD Phase 2 is not 
required. 

Networks subject to the Interoperability Directive have to implement FM using USSD Phase 2. 

NOTE: As an option, these networks may also implement FM using USSD Phase 1. 



Information stored in the network entities 



5.1 



Information stored in HLRa and FFNb 



The HLRa shall store: 

the state of FM (which shall be one of the valid states listed below). 
The FFNb shall store: 

the state of FM if the remote party is a GSM subscriber; 

the registration parameter: 

- the initiating number (MSISDNa). 
The following logical states are applicable for FM (refer to TS 23.01 1 for an explanation of the notation): 
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Provisioning State 

(Not Provisioned, 
(Provisioned, 



In HLRa (for the initiating subscriber) 
Registration State Activation State 

Not Registered, Not Active, 

Not Registered, Not Active, 



HLR Induction State 

Not Induced) 
Not Induced) 



The registration and activation state is the same for each applicable elementary basic service group 
The provisioning state shall be per subscriber, and hence the same for all basic service groups. 

In FFNb (for the remote party). 
Registration State Activation State 

Not Registered, Not Active, 

Not Registered, Not Active, 

Registered, Active and Operative, 

The registration and activation state is the same for each applicable elementary basic service group 
The provisioning state shall be per subscriber, and hence the same for all basic service groups. 



Provisioning State 

(Not Provisioned, 

(Provisioned, 

(Provisioned, 



HLR Induction State 

Not Induced) 
Not Induced) 
Not Induced) 



5.2 



State transition model 



The following figure shows the successful cases of transition between the applicable logical states of FM. The state 
changes are caused by actions of the service provider, the mobile user or the network. 

NOTE: Error cases are not shown in the diagram as they do not normally cause a state change. Successful 
requests that do not cause a state change are not shown in the diagram. 

The diagram only shows operations on an elementary basic service group. 



Provisio 




Figure 5.1 : State transition model for FM 
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5.3 Information stored in the VLR 

There is no FM information stored in the VLR. 

5.4 Transfer of information from HLR to VLR 

There is no FM information transferred from HLR to VLR. 
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Annex A (informative): 

Checking matrix for FIVI-CFU interaction in FFNb 

The following table is applicable under the assumption that FM and CFU are always provisioned to the remote party. 
If FM is not provisioned then there is no interaction between FM and CFU. 
If FM is Registered and Active, CFU must also be Registered and Active. 
Interrogation of both FM and CFU is allowed in any registration state. 

Table A.1 : Operation allowance check according registration states of FM and CFU (informative) 



Operation 


Registration States 


Outcome 


FIVI 


CFU 


Registration FM 


Not registered 


Not registered 


FIVI: Registered and Active 
CFU: Registered and Active 


Registered, active 


operation not allowed 


operation not allowed 


registered and active 


Registered, active 


see note 1 


Erasure FIVl 


Not registered 


Not registered 


operation not allowed, 
see note 2 


.BPS'sterpd'. CPA^PJ^'ve 

Registered, active 


operation not allowed 


operation not allowed 


registered and active 


Registered, active 


FM: Not Registered 
CFU: Not Registered 


Registration 
CFU 


Not registered 


Not registered 


FM: Not registered 

CFU: Registered, active 

see note 3 


Registered, not active 


FM: Not registered 

CFU: Registered, active 

see note 3 


Registered, active 


FM: Not registered 

CFU: Registered, active 

see note 3 


registered and active 


Registered, active 


operation not allowed, 
see note 4 


Erasure CFU 


Not registered 


Not registered 


operation not allowed, 
see note 3 


Registered, not active 


FM: Not registered 

CFU: Not registered 

note 3 


Registered, active 


FM: Not registered 

CFU: Not registered 

see note 3 


registered and active 


Registered, active 


operation not allowed, 
see note 4 


Activation CFU 


Not registered 


Not registered 


operation not allowed, 
see note 3 


Registered, not active 


FM: Not registered 

CFU: Registered, active 

see note 3 


Registered, active 


FM: Not registered 

CFU: Registered, active 

see note 3 


registered and active 


Registered, active 


operation not allowed, 
see note 4 


Deactivation 
CFU 


Not registered 


Not registered 


operation not allowed, 
see note 3 


Registered, not active 


operation not allowed, 
see note 3 


Registered, active 


FM: Not registered 

CFU: Registered, not active 

see note 3 
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Operation 


Registration States 


Outcome 


FIVI 


CFU 


registered and active 


Registered, active 


operation not allowed, 
see note 4 


NOTE 1 : The operation is only allowed when the registration is made by the same initiating subscriber. The 
registration states of FM and CFU shall not be changed by the operation. 

NOTE 2: The outcome code should be "Remote party not registered". 

NOTE 3: Refer to TS 23.082 for CFU handling. 

NOTE 4: Conflicting situation with other supplementary service (see TS 22.082: Exceptional procedures or 
unsuccessful outcome). 
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Annex B (normative): 

FM control Messages and their contents 

B.1 General principles 

All messages used for the control of FM are based on mobile initiated USSD. The principles of USSD can be found in 
TS 22.090, TS 23.090, TS 24.090 and TS 29.002. 

The present document is only concerned with the contents of the USSD strings. 

B.2 Information Elements used in the messages 

The operation code 

The operation code is defined in TS 22.030 for the control of Supplementary Services and consists of the two 
characters: 

** for Registration; 

## for Erasure; 

*# for Interrogation. 

The Service Codes 

The Service Code is service specific for FM. 

The remote number 

The remote number is the basic MSISDN of the remote party if the remote party is a GSM subscriber. It is entered by 
the initiating subscriber as part of the registration request. It is a number in international format. 

Additional information field 

An additional information field which does not exceed 30 octets may be optionally included in all FM control messages 
to convey operator specific information to the FFNb. The content and use of this additional information is operator 
specific and out of scope of the present document. 

The initiating number 

The initiating number is the basic MSISDN of the initiating subscriber. It is derived by HLRa from the IMSI of the 
initiating subscriber. 

This parameter is used in international format according to the scheme: 

country code, national (significant) number. 

B.3 Messages Contents of the FM Request 

Contents of the USSD string of FM-Request: 

all parameters are entered by the initiating subscriber and transported transparently to HLRa. 
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Table B.I : Contents of the USSD string of FM-Request 



Parameter 
number 


Value 


Parameter 
mandatory (M) 
or optional (0) 


Comment 


1 


OC 


M 


Operation Code: 
OC = ** ... for Registration 
OC = ##... for Erasure 
OC = *# ... for Interrogation 


2 


sc 


M 


Service Code for Follow Me. SMG1 Refer to 22.030 
for the Service Code for Follow Me. 


3 


* 


M 


Delimiter 


4 


REMOTE 
NUMBER 


M 


remote number 


5 


* 


M 


Delimiter. 


6 


Supervisor 
Indicator 


C 


Supervisor Indicator = 88. Used for Forced Erasure 
by FM Service Supervisor. 


7 


* 


M 


Delimiter 


8 


MSISDN 


C 


MSISDN of previous initiating subscriber who has 
registered the FM to remote number. This 
parameter is conditional, only used for forced 
erasure. 


9 


* 


M 


Delimiter 


10 


Additional 
information field 





For operator specific use 


last 


# 


M 


End of USSD string 



B.4 Messages Contents of the HLR-FM-Request 

Contents of the USSD string of HLR-FM- Request is the same of FM-Request described in clause B.3. Additionally, the 
MSISDNa is sent to the FFNb together with the FM-Request within the MAP operation. Contents of the FM -Response 

Messages. 

The FM-Response messages which are generated by the HLR, as well as the HLR-FM-Response messages which are 
received by the HLR from the FFN and are forwarded unchanged as FM-Response messages to the MS, contain the 
following two parts: 

mandatory part: two digit outcome codes, which are interpreted in the MS according to operator specific 
requirements; 

optional part: the response texts. 

The optional part is separated by a space character as separator which occurs together with the optional part. 

These outcome codes indicating success or error of the requested FM operation are 2 USSD characters according to the 
following table (table B.2). 
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Table B.2 Outcome codes for FM-Response 



Scenario 


Text examples for MS display 


Req 


Era 


Interro 


Outcome 
Code 


Outcome codes for successful 
cases 










00 series 


Success registration Case 


Follow Me activated 


X 






01 


Success erasure Case 


Follow Me deactivated 




X 




02 


Success interrogation Case 


Follow Me active to 

<MSISDN> 

The MSISDN digits are sent in 

the USSD response separated 

by a blank character from the 

outcome code. 






X 


03 


Operator Specific outcome codes 










04-06 


Reserved for future enliancement 










07-09 


Spare outcome codes 










10 series 














Outcome codes generated at 
the HLRa in non-successful 
cases 










20,30 
series 


Incoming barrings 


Illegal interaction with incoming 
barring 


X 


X 


X 


21 


Unautliorised request 


Unauthorised request 


X 


X 


X 


22 


Operator Specific outcome codes 










23-30 


Reserved for future enliancement 










31-39 


Outcome codes generated at 
both the HLRa and the FM 
function node in non- 
successful cases 










40 series 


Unl<nown remote party 


Unknown remote party 


X 


X 


X 


41 


FIVI not subscribed 


FM not subscribed 


X 


X 


X 


42 


Operator Specific outcome codes 










43-45 


Reserved for future enliancement 










46-49 














Spare unsuccessful outcome 
codes 










50 series 














Outcome codes generated at 
the FM function node in non- 
successful cases 










60,70 
series 


Remote party already 
registered 


Remote party already registered 


X 






61 


FM not registered to remote party 


FMnot 

registered to remote party 




X 


X 


62 


Remote party not registered to 
this MSISDN 


Remote party not 
registered to this MSISDN 




X 




63 


Remote Party Authorisation failed 


Unauthorised changes to remote 
party 


X 


X 




64 


Call Forwarding active or 
registered 


Illegal interaction with call 
forwarding 


X 






65 
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Scenario 


Text examples for MS display 


Req 


Era 


Interro 


Outcome 
Code 


Incoming or outgoing barrings 


Illegal interaction with call 
barrings 


X 


X 




66 


Request to own IVISISDN not 
possible 


Request to own MSISDN not 
possible 


X 






67 


Operator Specific outcome codes 










68-72 


Reserved for future enhancement 










73-79 


Outcome codes could be sent 
back by CFU processes in 
unsuccessful cases 












forwarded-to number is invalid 
directory number 


forwarded-to number is invalid 
directory number 


X 






80 


insufficient information 


insufficient information 


X 


X 




81 


forwarded-to number is a special 
service code 


forwarded-to number is a special 
service code (e.g. police) 


X 






82 


Conflicting situation with other 
supplementary services 


Conflicting situation with other 
supplementary services (e.g. 
incoming call barring has been 
activated) 


X 




X 


83 


Inconsistent with registration 


Inconsistent with registration 




X 




84 


Spare unsuccessful outcome 
codes 










85-99 
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